System And Method Of Operation Control On An Electronic Device

ABSTRACT

Systems and methods of application control for use on an electronic device. A device can be configured to receive an operation request from an application. The device can determine whether the requested operation is allowed to be performed by the application based upon a stored authorization record and an application identifier associated with the application. The application is allowed to perform the requested operation based upon whether the requested operation is determined to be allowed to be performed by the application.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/118,748, entitled “System and Method of Operation Control on anElectric Device,” the entirety of which (including any and all figures)is herein incorporated by reference. This application claims priority toand the benefit of U.S. Provisional Application Ser. No. 60/567,163,filed on Apr. 30, 2004, of which the entire disclosure (including anyand all figures) is incorporated herein by reference.

This application claims priority to and the benefit of U.S. applicationSer. No. 10/732,132 (entitled “System and method of owner control ofelectronic devices” filed Dec. 10, 2003), which claims priority to U.S.provisional patent application Ser. No. 60/432,610 (entitled “System andmethod of owner control of electronic devices” filed Dec. 12, 2002). Bythis reference, the full disclosure, including the drawings, of U.S.application Ser. Nos. 60/432,610 and 10/732,132, are incorporated hereinby reference.

BACKGROUND

This system relates generally to electronic devices, and in particularto controlling application installation of such devices by a deviceowner.

In a corporate environment, employees are often provided with access tooffice supplies and equipment to be used in performing job functions.Standard equipment typically includes at least a personal computer (PC),and may also include wireless mobile communication devices and othertypes of electronic devices. Although such equipment is intendedprimarily for business or work-related purposes, users sometimes makepersonal use of office equipment. Employers may be comfortable with somedegree of personal use of such equipment, provided that the personal usedoes not interfere with normal job functions, does not incur additionalcosts, and conforms with company policies.

In these types of situations, a user of an electronic device is not theowner of the device, and the user and owner may have differentperceptions of acceptable device uses. Acceptable uses may be specifiedin company policies, for example, which employees are expected tofollow, but beyond company policy statements, a corporate device owneroften has little if any control over how electronic devices areultimately used. According to one known scheme for controlling operationof electronic devices, an owner loads a policy file onto a device torestrict the type of operations or software applications that may beexecuted by the device. However, this type of scheme is sometimescircumvented by a user by either deleting the owner policy file orreplacing the owner policy file with a user policy file which mayinclude fewer restrictions than the owner policy file. Therefore, thereremains a need for a system and method of owner application control ofelectronic devices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing a communication system in whichelectronic devices are used.

FIG. 2 is a block diagram illustrating a system of inserting ownerinformation and owner control information onto an electronic device.

FIG. 3 is a block diagram of an electronic device in which a system andmethod of owner control are implemented.

FIG. 4 is a flow diagram illustrating a method of inserting ownerinformation onto an electronic device.

FIG. 5 is a flow diagram illustrating a method of inserting ownercontrol information onto an electronic device.

FIG. 6 is a flow diagram showing a method of owner control of anelectronic device.

FIG. 7 is a block diagram of a wireless mobile communication device asan example of an electronic device.

FIG. 8 is a flow diagram illustrating a method of device initializationof required applications.

FIG. 9 depicts an exemplary user interface on a remote server for anowner to designate application control information for dissemination toparticular devices, or groups of devices.

DETAILED DESCRIPTION

FIG. 1 is a block diagram showing a communication system in whichelectronic devices are used. The communication system 10 includes a WideArea Network (WAN) 12, coupled to a computer system 14, a wirelessnetwork gateway 16 and a Local Area Network (LAN) 18. The wirelessnetwork gateway 16 is also connected to a wireless communication network20 in which a wireless mobile communication device 22 (“mobile device”),is configured to operate.

The computer system 14 is a desktop or laptop PC, which is configured tocommunicate to the WAN 12, the Internet for example. PCs, such as thecomputer system 14, normally access the Internet through an InternetService Provider (ISP), Application Service Provider (ASP) or the like.

The LAN 18 is an example of a typical working environment, in whichmultiple computers 28 are connected in a network. It is normally locatedbehind a security firewall 24. Within the LAN 18, a message server 26,operating on a computer behind the firewall 24, acts as the primaryinterface for the corporation to exchange messages both within the LAN18, and with other external messaging clients via the WAN 12. Knownmessage servers include, for example, Microsof™ Exchange Server andLotus Domino™. The LAN 18 includes multiple computer systems 28, each ofwhich implements a messaging client, such as Microsoft Outlook™, LotusNotes™, Yahoo™ Messenger, AOL Instant Messenger, or other client-serveror peer-to-peer, or similar messaging clients with variousarchitectures. Messages received by the message server 26 aredistributed to mailboxes for user accounts addressed in the receivedmessages, and are then accessed by a user through a messaging clientoperating on a computer system 28. The fact that the example givenillustrates a client-server architecture in no way implies that sucharchitecture is necessary, as other architectures may be used.

Although only a message server 26 is shown in the LAN 18, those skilledin the art will appreciate that a LAN may include other types of serverssupporting resources that are shared between the networked computersystems 28, and that the message server 26 may also provide additionalfunctionality, such as dynamic database storage for data such as, butnot limited to, calendars, to-do lists, task lists, e-mail anddocumentation. The message server 26 and electronic messaging aredescribed for illustrative purposes only. Owner control systems andmethods are applicable to a wide range of electronic devices, and are inno way limited to electronic devices with messaging capabilities.

The wireless gateway 16 provides an interface to a wireless network 20,through which messages may be exchanged with a mobile device 22. Suchfunctions as addressing of the mobile device 22, encoding or otherwisetransforming messages for wireless transmission, and any other interfacefunctions are performed by the wireless gateway 16. The wireless gateway16 may be configured to operate with more than one wireless network 20,in which case the wireless gateway 16 also determines a most likelynetwork for locating a given mobile device 22 and possibly track mobiledevices as users roam between countries or networks.

The mobile device 22 is, for example, a data communication device, avoice communication device, a dual-mode communication device such asmany modern cellular telephones having both data and voicecommunications functionality, a multiple-mode device capable of voice,data and other types of communications, a personal digital assistant(PDA) enabled for wireless communications, or a laptop or desktopcomputer system with a wireless modem.

Any computer system with access to the WAN 12 may exchange messages withthe mobile device 22 through the wireless network gateway 16.Alternatively, private wireless network gateways such as wirelessVirtual Private Network (VPN) routers could be implemented to provide aprivate interface to a wireless network. A wireless VPN routerimplemented in the LAN 18 provides a private interface from the LAN 18to one or more mobile devices such as 22 through the wireless network20. A private interface to a mobile device 22 may also effectively beextended to entities outside the LAN 18 by providing a messageforwarding or redirection system that operates with the message server26. Such a message redirection system is disclosed in U.S. Pat. No.6,219,694, which is hereby incorporated into this application byreference. In this type of system, incoming messages received by themessage server 26 and addressed to a user of a mobile device 22 are sentthrough the wireless network interface, either a wireless VPN router,the wireless gateway 16, or another interface, for example, to thewireless network 20 and to the user's mobile device 22. Anotheralternate interface to a user's mailbox on a message server 26 may be aWireless Application Protocol (WAP) gateway. Through a WAP gateway, alist of messages in a user's mailbox on the message server 26, andpossibly each message or a portion of each message, may be sent to themobile device 22.

A wireless network 20 normally delivers messages to and fromcommunication devices such as the mobile device 22 via RF transmissionsbetween base stations and devices. The wireless network 20 may, forexample, be a data-centric wireless network, a voice-centric wirelessnetwork, or a dual-mode network that can support both voice and datacommunications over the same infrastructure. Recently developed networksinclude Code Division Multiple Access (CDMA) networks and General PacketRadio Service (GPRS) networks. So-called third-generation (3G) networkslike Enhanced Data rates for Global Evolution (EDGE) and UniversalMobile Telecommunications Systems (UMTS) are currently underdevelopment. Older data-centric networks include, but are not limitedto, the Mobitex™ Radio Network (“Mobitex”), and the DataTAC™ RadioNetwork (“DataTAC”). Voice-centric data networks such as PersonalCommunication System (PCS) networks, including Global System for MobileCommunications (GSM) and Time Division Multiple Access (TDMA) systems,have been available in North America and world-wide for several years.

In the system 10, a company that owns the LAN 18 may provide a computersystem 28 and/or a mobile device 22 to an employee. When a computersystem 28 issued to an employee is a laptop computer, for example, thecomputer system 28 may be used either within or outside the corporateLAN 18. When the computer system is operating within the LAN 18,non-local operations may be restricted by configuring permissions andrestrictions for the computer system 28, a network account of the user,or both, in such a way that the permissions and restrictions are notconfigurable by the user. However, if a user is using a computer outsidethe LAN 18, by connecting the computer to the WAN 12 as shown at 14, forexample, network-based controls in place at the LAN 18 can sometimes bebypassed.

In order to maintain control over an electronic device such as thecomputer system 28 or mobile device 22, an owner may establish localsettings directly on the device. Such local settings control deviceoperations, but only as long as the settings remain intact on thedevice. A common problem with this type of control mechanism is thatlocal settings may be deleted, replaced, or otherwise altered by a user.

In some instances, the owner control information can include one or moreapplications lists. The application lists provide owner control ofapplication installation and deletion on the electronic device. As anexample, application lists can address different types of applications,such as but not limited to:

-   -   Required applications: These applications must be present on the        device before the user may use the device; alternatively, one or        more operations of the device can be disabled until such        applications are available for execution on the device. This        will allow the owner to install audit and remote administrative        applications. The user can in some implementations be prevented        from deleting these applications. This list may be small.    -   Allowable (or authorized) applications: These applications may        or may not be present on a device. Thus the user is free to        download these applications if they desire the functionality        that the application provides. This list may be small.    -   Excluded applications: These applications may not be present on        a device. Presumably an excluded application is a malicious        application, or otherwise undesirable application. This list is        potentially large.

With respect to allowed and/or required applications, even if theapplications are required or allowed on the device, the owner may wantto impose restriction on operations that such applications can perform.For instance, the owner may want to control functionality such as:

1) Is the application allowed to open network connections inside thefirewall (e.g., via MDS)?

2) Is the application allowed to open network connections outside thefirewall (e.g., via WAP, device TCP, SMS)?

3) Is the application allowed to open local connections (e.g., serial,IR, or USB connections)?

4) Is the application allowed to interact with other processes? Is theapplication allowed to access a Runtime Store or a Persistent Store?

5) Is the application allowed access to a telephone API (e.g., to makephone calls)?

FIG. 2 is a block diagram illustrating a system of inserting ownerinformation and owner control information onto an electronic device;such an insertion system may be used in one or more implementations ofthe described owner application control systems and methods. Theforegoing explanation is therefore exemplary in nature. The system inFIG. 2 includes an electronic device 210, an owner information insertionpoint 220, and an owner control information insertion point 230. Theowner information insertion point 220 is alternatively referred to as abranding point, while the owner control insertion point 230 isalternatively referred to as a control point. An owner information store212, an owner control information store 214, and an interface/connector216 are provided in the electronic device 210. The owner informationinsertion point 220 includes an owner information source 224 and aninterface/connector 222. The owner control information insertion point230 similarly includes an owner control information source 234 and aninterface/connector 232.

The owner information store 212 stores information, such as an ownername or other identification information, for example, which identifiesan owner of the electronic device 210. The owner control informationstore 214 stores information that is used to control the operation ofthe electronic device 210. Owner control information may, for example,be specified in an authorization record that lists software applicationsauthorized to be installed and executed on the electronic device 210;authorization records can further constrain operations performed byinstalled applications. The use of owner control information to controloperations of an electronic device is described in further detail below.The owner information source 224 and the owner control informationsource 234 could be local memory devices, communication modules throughwhich remote memory devices storing owner information and owner controlinformation are accessible, or possibly user interfaces through whichowner information and owner control information are entered.

The interface/connector 222 is compatible with the interface/connector216 to establish a communication link between the owner informationinsertion point 220 and the electronic device 210, to thereby enableowner information to be transferred to the electronic device 210 fromthe owner information source 224. The interface/connector 232 similarlyenables transfer of owner control information from the owner controlinformation source 234 onto the electronic device 210 via acommunication link established between the interface/connectors 232 and216. The interface/connectors 216, 222, and 232 may establish wiredcommunication links, where the interface/connectors are serial ports,for example, or wireless communication links such as infrared linkswhere the interface/connectors are infrared modules. Owner informationand owner control information transferred to a device are respectivelyinserted or stored in the owner information store 212 and the ownercontrol information store 214.

The owner control insertion point 220 is associated with an owner of theelectronic device 210. Where the electronic device 210 is provided to auser by an employer, for example, the owner control insertion point 220may be a computer system or device controlled by a corporate computersystem administrator or IT department. The electronic device 210 is“branded” with owner information by establishing a communication linkbetween the owner information insertion point 220 and the electronicdevice 210 through the interface/connectors 222 and 216 and theninserting owner information into the owner information store 212. Unlessotherwise desired, once owner information has been inserted onto themobile device 210, then there can be a configuration such that only theowner or a party authorized by the owner is able to change the ownerinformation or insert or change owner control information on theelectronic device 210.

Because insertion of owner control information onto the electronicdevice 210 is restricted once owner information has been inserted, theowner control information insertion point 230 need not necessarily becontrolled by the owner of the electronic device 210. When the ownermaintains control over the owner control information insertion point230, the insertion points 220 and 230 may be implemented in the samecomputer system or device and share the same interface/connector.However, separate insertion points 220 and 230 as shown in FIG. 2 allowan owner of the electronic device to delegate owner control informationinsertion to a trusted entity. If owner control information insertion iscontrolled using digital signatures, for example, as described infurther detail below, an owner first brands the electronic device 210and provides the electronic device 210 and digitally signed ownercontrol information to a user. In this case, the owner controlinformation insertion point 230 may be the user's computer system, whichis then used to insert the digitally signed owner control informationonto the electronic device 210.

In most implementations, the owner information insertion point 220 andthe owner control information control point 230 include the same type ofinterface/connectors 222 and 232, compatible with theinterface/connector 216 in the electronic device 210. However, theelectronic device 210 may alternatively include multipleinterface/connectors, such that different types of interface/connectorsmay be implemented at an owner information insertion point 220 and anowner control information insertion point 230. Although only a singleowner control information insertion point 220 and owner controlinformation insertion point 230 are shown in FIG. 2, a completeinsertion system may include more than one of each type of insertionpoint. In a large company, for example, corporate computer systemadministrators may be authorized to perform owner information insertionoperations from administrator computer systems, or from any corporatecomputer system from which administrative functions can be accessed,thereby providing multiple owner information insertion points 220.Similarly, when an owner allows users to insert digitally signed ownercontrol information onto electronic devices, as described above, eachuser's computer system may be used as an owner control informationinsertion point 230.

The systems and methods of owner application control can use theinsertion structures and methods described above; however, so long asowner control information store is capable of storing a requiredapplication list, and in some instances an allowed application listand/or an excluded application list, the particular control informationinsertion system and method can vary significantly, and use anyconventional insertion/interfacing technology, without impacting theowner application control systems and methods discussed herein.

FIG. 3 is a block diagram of an electronic device in which a system andmethod of owner application control can be implemented. In FIG. 3, theelectronic device is a mobile device 30 adapted to operate within awireless network. Also shown in FIG. 3 is an insertion tool 64 used toinsert owner information onto the mobile device 30.

It should be apparent to those skilled in the art that only thecomponents involved in an owner control system are shown in FIG. 3. Amobile device typically includes further components in addition to thoseshown in FIG. 3. Also, the mobile device 30 is an illustrative exampleof an electronic device for which an owner may wish to enforce some sortof usage policy. An owner may also wish to control the usage of othertypes of electronic devices, such as mobile telephones, laptop computersand PDAs, for example.

As shown in FIG. 3, a mobile device 30 comprises a memory 32, aprocessor 40, an application loader 42, an insertion module 44, a userinterface (UI) 46, a wireless transceiver 48, and an interface/connector50. The memory 32 can include a software applications store 34, an ownerinformation store 36, an authorization record store 38, as well aspossibly other data stores associated with other device systems inaddition to those shown in FIG. 3.

The memory 32 is a writable store such as a RAM or Flash memory intowhich other device components may write data. However, write and eraseaccess to the software application store 34, the owner information store36, and the authorization record store 38 may be restricted, but neednot be in all implementations. For example, a user of the mobile device30 may be able to retrieve data from the stores 34, 36, and 38, butwrite and erase operations for these stores are controlled, as describedbelow. The software application store 34 includes software applicationsthat have been installed on the mobile device 30, and may include, forexample, an electronic messaging application, a personal informationmanagement (PIM) application, games, as well as other applications. Theowner information store 36 stores information such as an owner name orother identification, data integrity and source authenticationinformation, such as a digital signature public key associated with adigital signature private key of the owner. Owner control information,in which an owner of the mobile device 30 specifies usage permissionsand restrictions for the mobile device 30, is stored in an authorizationrecord in the authorization record store 38. Such authorization recordscan include one or more of the aforementioned required, allowed and/orexcluded application lists, or more specific operation constraints forspecific allowed and/or required applications. It should be appreciatedthat the supported lists need not be stored as a unit; rather, the listscan logically be formed from authentication records associated withindividual applications, wherein the each application authenticationrecords includes a field that designates the application appropriately(e.g., allowed, required, excluded, etc.) and can include a fieldcontaining an application identifier.

The processor 40 is connected to the wireless transceiver 48 and thusenables the mobile device 30 for communications via a wireless network.The application loader 42 and insertion module 44, described in furtherdetail below, are connected to the interface/connector 50 to allowcommunication with the insertion tool 64, through the co-operatinginterface/connector 52.

The UI 46 includes one or more UI components, such as a keyboard orkeypad, a display, or other components which accept inputs from orprovide outputs to a user of the mobile device 30. Although shown as asingle block in FIG. 3, it should be apparent that a mobile device 30typically includes more than one UI, and the UI 46 is therefore intendedto represent one or more user interfaces.

The insertion tool 64 includes an owner information store 60 and aninterface/connector 52 through which information is exchanged with themobile device 30, and thus represents an owner information insertionpoint 220 (FIG. 2). As described above, an owner information insertionpoint such as the insertion tool 64 is normally controlled by an ownerof an electronic device. Therefore, the insertion tool 64 is, forexample, implemented on an administrator computer system used by anauthorized administrator to enable services for or otherwise configurethe mobile device 30. Because networked computer systems can typicallybe used by any user, the insertion tool 64 may instead be accessible toany computer system in a corporate network, dependent upon theparticular user that is currently “logged on” the computer system.

The owner information store 60 stores owner information to be insertedonto the mobile device 30, and may be implemented, for example, on alocal memory component such as a RAM chip, a flash memory device, or ahard disk drive. When the insertion tool 64 is implemented in anetworked computer system or other network-connected device, the ownerinformation store 60 may be a remote memory system such as a file serverthat is accessible to the insertion tool 64 through a networkconnection. The owner information store 60 may instead incorporate amemory reader such as a smart card reader, a memory card reader, afloppy disk drive, or a CD or DVD drive, for example.

Information is transferred between the insertion tool 64 and the mobiledevice 30 via a communication link established between theinterface/connectors 50 and 52. The interface/connectors 50 and 52 couldbe any of a plurality of compatible data transfer components, including,for example, optical data transfer interfaces such as Infrared DataAssociation (IrDA) ports, other short-range wireless communicationsinterfaces, or wired interfaces such as serial or Universal Serial Bus(USB) ports and connections. Known short-range wireless communicationsinterfaces include, for example, “Bluetooth” modules and 802.11 modulesaccording to the Bluetooth or 802.11 specifications, respectively. Itwill be apparent to those skilled in the art that Bluetooth and 802.11denote sets of specifications, available from the Institute ofElectrical and Electronics Engineers (IEEE), relating to wireless LANsand wireless personal area networks, respectively. Therefore, acommunication link between the insertion tool 64 and the mobile device30 may be a wireless connection or a physical wired connection.

Because communications between the insertion tool 64 and the mobiledevice 30 need not necessarily be accomplished using a physicalconnection, references to connecting a mobile device to an insertiontool include establishing communications through either physicalconnections or wireless transfer schemes. Thus, the mobile device 30could be connected to the insertion tool 64 by connecting serial portson the mobile device 30 and the insertion tool 64, by positioning themobile device 30 such that an optical port thereof is in a line of sightof a similar port of the insertion tool 64, or by connecting orarranging the mobile device 30 and the insertion tool 64 in some othermanner so that data may be exchanged. The particular operations involvedin establishing communications between a mobile device and an insertiontool are dependent upon the types of interfaces and/or connectorsavailable in both the mobile device and the insertion tool.

Owner branding of the mobile device 30 may be facilitated by insertingowner information onto the mobile device 30 using the insertion tool 64before the mobile device 30 is operable by a user. This may beaccomplished, for example, by pre-loading owner information before themobile device 30 is provided to the user by the owner, or before themobile device 30 is configured for use. In the former example, the ownermaintains physical control of the mobile device 30 until ownerinformation has been loaded, whereas in the latter example, the user haspossession of the mobile device 30 but is in this example unable to makeuse of the device until it is configured by, or at least under thecontrol of, the owner.

Pre-loading of owner information onto the mobile device 30 can beperformed using the insertion tool 64. The insertion tool 64 may be acomputer system associated with an a owner system administrator, or acomputer system which may be used by a mobile device user oradministrator. Depending upon the owner information pre-loading scheme,the insertion tool 64 is operated by a mobile device user or anadministrator.

When the mobile device 30 has been connected to the insertion tool 64,owner information is retrieved from the owner information store 60 andtransferred to the mobile device 30 through the interface/connectors 52and 50, and passed to the insertion module 44 on the mobile device 30,which stores the owner information to the owner information store 36 inthe memory 32.

Although the insertion module 44 is shown in FIG. 3 as being connectedto the interface/connector 50, this module can be implemented as asoftware module or application that is executed by the processor 40. Assuch, data transfers to and from the interface/connector 50 may actuallybe accomplished by routing data through the processor 40 to theinterface/connector 50. In this case, the processor 40 may be instructedby the insertion tool 64 to start the insertion module 44 before theowner information is transferred to the mobile device 30. Alternatively,the processor 40 may be configured to start the insertion module 44whenever owner information is received. The insertion tool 64 maysimilarly be a software module or application that is executed by aprocessor (not shown) in a computer system or device on which theinsertion tool 64 operates.

The owner information that is pre-loaded onto the mobile device 30 mayinclude data integrity and/or source authentication information, such asa cryptographic system like a digital signature public key whichcorresponds to a digital signature private key used by the owner todigitally sign information before it is transferred to the mobile device30. Pre-loading of the data integrity and/or source authenticationinformation enables greater security of owner control operations, asdescribed in further detail below in the context of digital signatures.Owner information may also include, for example, a name or otheridentifier associated with the owner of the mobile device 30.

In an owner control scheme in which digital signatures are used toverify data integrity and authenticate a source of data, when theowner's digital signature public key has been inserted into the ownerinformation store 36 on the mobile device 30, owner control information,which specifies permissions and/or restrictions for the mobile device30, is inserted onto the mobile device 30. Although an owner informationinsertion point, insertion tool 64, is shown in FIG. 3, it will beapparent from FIG. 2 and the above description that owner controlinformation is usually inserted onto an electronic device after thedevice has been branded by inserting owner information onto the device.An owner control information insertion tool (not shown) configured foruse with the mobile device 30 is similar to the insertion tool 64,including an owner control information store and an interface/connectorcompatible with the interface/connector 50. Owner control information isinserted onto the mobile device 30 and stored in the form of anauthorization record in the authorization record store 38. In anauthorization record, an owner of the mobile device 30 specifies a listof software applications that a user is authorized to install on themobile device 30, as well as possibly a list of required softwareapplications that must be installed on the mobile device 30.

In order to prevent a user from inserting false owner controlinformation to thereby circumvent owner control, owner controlinformation can be digitally signed using the owner's digital signatureprivate key before being transferred to the mobile device 30. Theinsertion module 44 may be configured to verify the digital signaturebefore the owner control information is stored on the mobile device 30.If digital signature verification fails, then the owner controlinformation is not stored on the mobile device 30.

Digital signature schemes can involve some sort of transformation ofdigitally signed information to provide for checking the integrity ofthe information and authentication of a source of the signedinformation. For example, according to one known digital signaturetechnique, a digest of information to be digitally signed is firstgenerated using a non-reversible digest algorithm or transformation.Known digest algorithms include Secure Hashing Algorithm 1 (SHA-1) andMessage-Digest algorithm 5 (MD5). Other digest techniques that produce aunique digest for each unique input may also be used. The digest is thenfurther transformed using a digital signature private key and asignature algorithm to generate a digital signature. In digitalsignature verification, a digital signature public key corresponding tothe private key is used.

In the context of owner control and owner control information, insertionof the owner's digital signature public key on a mobile device 30 aspart of the owner information provides for digital signature-basedsecurity of owner control information. If some or all of the ownercontrol information is digitally signed before transfer to the mobiledevice 30, then the insertion module 44 can verify that owner controlinformation has actually been signed using the owner's digital signatureprivate key, known only to the owner, and that the owner controlinformation has not been changed since it was signed. In this example,only owner control information that originates with the owner of amobile device 30 is stored to and used on the mobile device 30.

Owner control information is obtained by an owner control informationinsertion tool from an owner control information store, which may be aremote data store accessible to the insertion tool, a local store, orsome form of memory reader, as described above. Owner controlinformation is established based on a set of software applications orfunctions that the owner wishes to authorize on an electronic device,and may tend to change relatively infrequently once established. Suchowner control information could then be digitally signed by a securecomputer system or software component to which only administrators haveaccess, using the owner's digital signature private key. In this case,signed owner control information is then stored at a location that isaccessible to administrator computer systems and possibly other computersystems, and retrieved by an owner control information insertion tool asrequired. The owner control information insertion tool then transfersthe signed owner control information to the mobile device 30. Dependingupon how often owner control information changes or is expected tochange, the signed owner control information may be further distributedto each computer system in a network in order to provide local access tosigned owner control information. When new owner control information isgenerated and signed, the signed new owner control information canreplace all existing copies of the owner control information, asdescribed in further detail below. Wide distribution of owner controlinformation provides easier access to the owner control information,whereas shared remote storage of owner control information requiresfewer updates when new owner control information is established.

It is also possible to support digital signature generation for ownercontrol information on an owner control information insertion tool.However, in the present example, this would require that the ownercontrol information insertion tool has access to the owner's digitalsignature private key. Unless otherwise desired, digital signing ofowner control information only by secure computer systems or componentsis generally preferred in that it limits the number of computer systemsthat can access the owner's digital signature private key.

When signed owner control information is transferred to the insertionmodule 44, digital signature verification operations are performed. Ifthe digital signature is verified, then the owner control information isstored on the mobile device 30 in the authorization record store 38.Otherwise, the owner control information is not stored. In the event ofa digital signature verification failure, an error or like indicationmay be output to a user on a UI 46 such as a display, an error messagemay be returned to the owner control information insertion tool, and anindication of the failure may also be output to a user of the ownercontrol information insertion tool. When owner control informationinsertion fails, retry or other error processing operations may beperformed on the owner control information insertion tool, the mobiledevice 30, or both.

Given the importance of the owner digital signature public key in thepresent example, at least a first owner information insertion operationfor any mobile device 30 is preferably either performed or at leastauthorized by an administrator, in order to ensure that accurate ownercontrol information is inserted onto the mobile device 30. This preventsa user from circumventing owner control by inserting a digital signaturepublic key other than the owner's digital signature public key onto themobile device 30.

When owner control information changes, where an owner wishes to expandor further restrict the use of an electronic device, for example, anyexisting owner control information may be replaced. As described above,new owner control information may be digitally signed, and the signednew owner control information is distributed to one or more locationsfrom which it is retrieved for insertion onto electronic devices.

Any of several mechanisms for subsequent distribution of signed newowner control information to electronic devices are possible. When newowner control information is distributed to each owner controlinformation insertion tool, the insertion tool may be configured todetect receipt of new owner control information, and to transfer the newowner control information to the mobile device 30 the next time themobile device 30 is connected to the owner control information insertiontool. As described above, an owner control information insertion point230 (FIG. 2), such as an owner control information insertion tool, maybe controlled by a user of an electronic device. Many modern electronicdevices are configured to be synchronized with computer systems. In suchsystems, this type of owner control information distribution may besupported by implementing an owner information control insertion tool ina user's computer system. New owner control information is thentransferred to the electronic device the next time the electronic deviceis synchronized with the computer system.

Alternatively, signed new owner control information may be sent by anowner to all owned mobile devices through a wireless network, via theLAN 18, the WAN 12, and the wireless network gateway 16, as shown inFIG. 1, for example. Such signed owner control information could be sentto the owned mobile devices either directly or through one or more ownercontrol information insertion tools. Although the owner's digitalsignature public key may be initially transferred to a mobile device 30through the interface/connectors 52 and 50, other communication linkswhich cannot be physically secured or protected, such as wireless orpublic communication network links, may be used to subsequently transfersigned owner control information to an electronic device that is enabledfor communications over such other links. When the owner's digitalsignature public key has been inserted on a mobile device 30, theinsertion module 44 is able to verify both the integrity and the sourceidentity of any signed owner control information received, whether it isreceived via the interface/connector 50 or the wireless transceiver 48.In this type of implementation, for example, an owner controlinformation insertion tool may include a different type of interface tothe mobile device 30 than the owner information insertion tool 64.

Initial storage of owner control information, as well as replacement ofexisting owner control information, is in this example thereby dependentupon verification of a digital signature by the insertion module 44.Other checks may also be performed before existing information isreplaced. In order to prevent replay attacks, in which old owner controlinformation is received by the electronic device, owner controlinformation can include version information. A configuration can includean existing owner control information being replaced only where receivedowner control information is newer than the existing owner controlinformation. Generally, newer owner control information has a higherversion number.

Although owner information is inserted onto the mobile device 30 usingthe insertion tool 64 as described above, changes to existing ownerinformation, such as when the owner's digital signature private/publickey pair is changed, may alternatively be updated on the mobile device30 using digital signature techniques. To this end, the insertion tool64 may include other types of communication modules (not shown), such asa wireless transceiver or network connector, for example, that are lesssecure than the interface/connector 52. In that case, any such updatesare dependent upon verification of a digital signature using a digitalsignature public key in existing owner information.

The foregoing description relates primarily to writing owner informationand owner control information to memory on an electronic device such asthe mobile device 30. However, an owner may also wish to erase ownerinformation and owner control information, without replacing existinginformation with new information. In this case, because information isnot being written to memory on a device, no signed owner information orowner control information would be sent to the device. Instead, an erasecommand or request may be sent to the device. Erasure may be a furtherfunction supported by the insertion module 44.

Referring again to FIG. 3, if owner information is to be erased from theowner information store 36, then an erase command or request isdigitally signed and sent to the insertion module 44. As with new ownerinformation or owner control information, a signed command or requestcould be sent to the mobile device 30 through either theinterface/connector 50 or the wireless transceiver 48. The insertionmodule 44, using the owner's digital signature public key, executes thecommand or completes the request if a digital signature is verified.Otherwise, the command or request may be ignored, and an error orfailure indication may be displayed to a user on a UI 46 on the mobiledevice 30, returned to a sending system or device that sent the commandor request, or both. Further error or failure processing routines maythen be performed at the sending system or device.

Since owner information includes the owner's digital signature publickey in a signature-based owner control scheme, erasure of ownerinformation can be tightly controlled. For example, only owner systemadministrators may be authorized to send erase commands or requests.Sending of signed commands or requests to the mobile device 30 can berestricted to administrator computer systems or accounts, an ownerinformation insertion tool, or an owner-controlled erasure tool. Forexample, an insertion tool such as the insertion tool 64 could beadapted to erase existing owner information from the mobile device 30 byproviding an erase command generator or store which is also coupled tothe interface/connector 52. Alternatively, owner information erasurecould be accomplished using a specialized, owner-controlled erasure toolincorporating such an erase command generator or store and an interfaceto the mobile device 30. Erasure of owner control information can becontrolled in a similar manner.

Where an owner control system is configured to support erasure andpossibly other owner information and owner control informationmanagement functions, access to the owner's digital signature privatekey may be restricted in order to control the information, requests, andcommands that can be digitally signed and sent to an electronic device.The digital signature private key or digital signature generationfunctions may be accessible only to specific computer systems oradministrator login accounts, for example.

As shown in FIG. 3, other systems on the mobile device 30 can haveaccess to the memory 32. Configurations may be used wherein no devicesystem is able to insert, change, or erase owner information or ownercontrol information without submitting properly signed information orcommands. Any data stores, such as the owner information store 36 andthe authorization record store 38, that store owner information or ownercontrol information can therefore be located in protected data stores(e.g., memory areas, etc.). Configuration may be used where only theinsertion module 44 has write and erase access to these stores, suchthat digital signature-based control of insertion and erasure of ownerinformation and owner control information are maintained. Other devicesystems have read only access to owner information and owner controlinformation. In one possible implementation, any systems or componentsthrough which the memory 32 is accessible are configured to allow memoryread operations from any locations in the memory 32, but deny any writeor erase operations to memory locations storing owner information orowner control information unless the operations originate with or areauthorized by the insertion module 44. In an alternative implementation,a memory manager (not shown) is provided to manage all memory accessoperations. Such a memory manager is configured to direct any write orerase operations involving owner information or owner controlinformation stores to the insertion module 44 for digital signaturechecking and authorization before completing the operations. Ownerinformation and owner control information may thereby be read by otherdevice systems, but preferably may only be inserted, changed, or erasedwhen a digital signature is verified.

It should be appreciated that the above public key digital signatureoperations are intended only as an illustrative example. Other digitalsignature schemes, or other data integrity checking and sourceauthentication schemes, may instead be used to verify the integrity andsource of owner control information or commands. Further, theauthentication and security described herein above can be used totransfer the owner application control information; however, varioussystems and methods of owner application control need not useauthentication and/or secure transmission in order to achieve thedesired owner application control as described herein.

In the mobile device 30, owner control information is included in anauthorization record that is stored in the authorization record store38. An authorization record specifies particular software applicationsthat are authorized for installation on the mobile device 30, and mayalso specify required software applications that must be installed onthe mobile device 30. Such an authorization record provides anelectronic device owner with relatively tight control of how a usermakes use of the mobile device 30, since only authorized softwareapplications can be loaded onto the device.

For authorized and/or required applications, some systems can provide amore fine grained control within the authorization record(s). In suchsystems, the owner can provide more specific controls on the operationsthat installed application can perform. Such controls can be specifiedon an individual application basis, or in some cases by groups ofapplications. Such operation controls can determine whether anapplication can connect to external resources, and if so, the channels(that may be used for such connections) can communicate with otherapplications executing on the device and/or can access part or all oflocal memory on the device.

Software application loading operations are enabled on the mobile device30 by the application loader 42. As described above in regard to theinsertion module 44, although the application loader 42 is shown asbeing connected to the interface/connector 50, information may actuallybe exchanged between the application loader 42 and theinterface/connector 50 or the wireless transceiver 48 through theprocessor 40.

Like owner information and owner control information, softwareapplications may be received by the mobile device 30 via theinterface/connector 50 or the wireless transceiver 48. One possiblesource of software applications configured for operation on the mobiledevice 30 is a user's computer system equipped with aninterface/connector compatible with the interface/connector 50. When thecomputer system is connected to a corporate LAN, for example, softwareapplications provided by a corporate owner of the mobile device 30 maybe retrieved from a file server on the LAN or other store on the LAN,and transferred to the mobile device. A computer system may also orinstead obtain software applications for the mobile device 30 from alocal store, or other sources, such as Internet-based sources, withwhich the computer system may communicate.

The application loader 42 may be configured to determine whether ownercontrol information is stored on the mobile device 30 whenever asoftware application is received. If no owner control information ispresent on the mobile device 30, then no owner controls have beenestablished for the mobile device 30, and the software application isinstalled. Alternatively, the application loader 42 could consult aremote server for an owner control information update prior toattempting the installation. Software application installation typicallyinvolves such operations as storing a received application file to thesoftware application store 34 in the memory 32, extracting files forstorage to the software application store 34, or possibly executing aninstallation program or utility. If owner control information issubsequently inserted onto the mobile device 30, existing softwareapplications may be checked by either the application loader 42 or theinsertion module 44 to ensure that all software applications resident onthe mobile device 30 are authorized software applications. Any softwareapplications that have not been authorized are erased from the mobiledevice 30 or otherwise rendered inoperable.

In some circumstances, owner information may have been inserted onto anelectronic device, but owner control information has yet to be inserted.In order to prevent loading of a software application onto the mobiledevice 30 that subsequently inserted owner control information does notauthorize, the mobile device 30 may be substantially disabled,permitting only a limited subset of device functions to be executed,until owner control information is inserted. Alternatively, theapplication loader 42 may be configured to determine whether ownerinformation is present on the mobile device 30 when a softwareapplication is received. Where owner information is found, indicatingthat owner control information will be established and used for themobile device 30, the application loader 42 then determines whetherowner control information has been inserted. In the event that ownerinformation but not owner control information is found, the applicationloader 42 does not load the received software application. Errorprocessing operations may then be performed, such as purging thereceived software application from any temporary memory location inwhich it was stored when received, and, if memory resources on themobile device 30 permit, storing the received software application onthe mobile device 30 in such a way that it is not executable. Anysoftware applications stored in this manner are then processed by theapplication loader 42 when owner control information is inserted ontothe mobile device 30. Although software applications are stored on themobile device 30 in this example, they would not be usable until ownercontrol information is inserted onto the mobile device 30, and it isconfirmed that the software applications are authorized forinstallation. The amount of memory space made available for suchsoftware applications may occupy can be limited, so that availablememory space will not be depleted by storing unchecked and possiblyunauthorized software applications.

When the application loader 42 determines that owner control informationhas been inserted onto the mobile device 30, the application loader 42then determines whether the received software application is authorizedfor installation on the mobile device 30. If the owner controlinformation includes an authorized software application list, theapplication loader 42 searches the list to determine whether thereceived software application is one of the authorized softwareapplications. Alternatively, an authorized (allowed) softwareapplication list residing on a remote or external device (e.g., remotecomputer system, external card or memory device, etc.) can be consultedto determine whether a particular application is authorized forinstallation. In some such cases, the approval response from the remoteor external device can include the application for installation, orinformation from which a source for the to-be installed application canbe obtained; upon receipt, the device can download and/or install theapplication based upon the received approval response.

An authorized software application list can include information thatuniquely identifies the authorized software applications, such as a hashof the software application source code or executable code, for example.Because a software application developer is free to choose a file namefor any software application, file names may not provide a reliableauthorization check. However, if an owner generates a hash of eachauthorized software application and includes the hash in the ownercontrol information that is inserted onto the mobile device 30, thenonly particular versions of authorized software applications can beinstalled on the mobile device 30. The application loader 42 generates ahash of any received software application, and installs the softwareapplication only if the generated hash matches a hash in the ownercontrol information. In order to support different hashing algorithms ondifferent electronic devices, a device owner generates more than onehash of each software application and includes each hash in the ownercontrol information inserted onto each owned electronic device. Anelectronic device may then use any of a number of different hashingalgorithms to generate a hash of a received software application. Otherunique transformations than hashes could also be used to generate ownercontrol information and to determine whether received softwareapplications are authorized for installation.

In some instances, prior to checking the authorized application list, atperiodic intervals or upon a remote authorization change, the device canreceive an authorized application list, or an authorized applicationlist update, from a remote server or external device controlled by thedevice owner. The list or list update can be received in response to arequest by the device (e.g., request a list or update upon installationattempt) or without such a request (e.g., responsive to an authorizationmodification by the owner on a remote owner administration server). Uponreceipt of an authorized list, the device can install the listoverwriting any prior list; upon receiving an update, the update isprocessed and integrated into an existing list, or used to create a listif none was present prior. In some instances the secure insertion tools,and/or other encryption/authentication, approaches as described hereincan be used to provide the authorized application list to the device.

Owner control information may also include a required softwareapplication list that uniquely identifies software applications that theowner of an electronic device establishes as mandatory; alternatively,such a required software application list could reside on a remote orexternal device (e.g., remote computer system, external card or memorydevice, etc.) that can be consulted at need. A required softwareapplication list allows an owner to ensure that every owned electronicdevice supports certain core functions, such as electronic messaging andsecure communications, for example.

Software applications in a required software application list may beuniquely identified by one or more hashes, as described above in thecontext of authorized applications. The processor 40, application loader42, insertion module 44, or a further device component or system isconfigured to periodically check to ensure that each required softwareapplication is present on the mobile device 30, and that a hash of eachrequired software application matches a hash in the required softwareapplication list. In addition, or instead, at power up or otherinitialization of the device, presence of required applications can bechecked. Where a required software application is not present on thedevice or its hash does not match a hash in the required softwareapplication list, which would occur when a software application has beenchanged, the mobile device 30, or at least some of its functions, can berendered unusable. Alternatively, the mobile device 30 can download andinstall missing or corrupted applications transparently to the user ofthe device; after successful installation of all required programs, thedevice is restored to operability.

In some instances, device initialization may include use of the requiredsoftware application list. Such a process is shown in FIG. 8. Adetermination is made as to whether required applications are availableon the device in step 800. The device examines installed applications todetermine if applications on the required software application list areavailable on the device. This can occur through examination of therequired software application list residing in the owner controlinformation store. Alternatively, identification information associatedwith installed applications can be transmitted to a remote servermanaged by the owner that performs the comparison and returns theresults of such a comparison to the device. If required applications aremissing the device is disabled in part, or in whole, in step 810. Thedevice may transparently initiate download of required applications thatwere determined to be unavailable 820. In implementations using a remoteserver to perform the comparison, some such implementations may allowthe remote server to directly return any missing applications to thedevice. When all required applications are present the device operatesnormally 840.

Prior to checking for the presence of required applications, at periodicintervals or upon a remote authorization change, the device can receivea required list, or a required list update, from a remote server orexternal device controlled by the device owner. The list or list updatecan be received in response to a request by the device (e.g., request alist or update at initialization) or without such a request (e.g.,responsive to an authorization modification by the owner on a remoteowner administration server). Upon receipt of a required list, thedevice can install the list overwriting any prior list; upon receivingan update, the update is processed and integrated into an existing list,or used to create a list if none was present prior. In some instancesthe secure insertion tools, and/or other encryption/authentication,approaches as described herein can be used to provide the requiredapplication list to the device.

In order to provide further control over required software applications,erasure or other operations involving such applications are controlled.Digital signature-based control of such functions is implemented byrequiring a digital signature on any erase or write command that affectsa required software application. When an erase or write command isreceived from a system on the mobile device 30 or from a remote systemvia the interface/connector 50 or wireless transceiver 48, the processor40 or another device system such as a memory manager (not shown)determines whether the command involves the software application store34. Such a write or erase command is not executed unless a digitalsignature is verified using the owner's digital signature public keystored on the mobile device 30. Although software applications may beexecuted by device systems without requiring digital signatures,required software applications, if so desired, may only be changed orerased when a digital signature is verified. As above, digitalsignatures represent one possible data integrity and sourceauthentication mechanism.

Owner control information may also include an excluded softwareapplication list that uniquely identifies software applications that theowner of an electronic device establishes cannot be installed on thedevice. An excluded software application list allows an owner to ensurethat every owned electronic device does not contain particular maliciousand/or counter productive software applications. Software applicationsin an excluded software application list may be uniquely identified byone or more hashes, as described above in the context of authorizedapplications. The processor 40, application loader 42, insertion module44, or a further device component or system is configured toperiodically check to ensure that no excluded software application ispresent on the mobile device 30, and that a hash of each presentsoftware application does not match a hash in the excluded softwareapplication list. Where an excluded software application is present onthe device or its hash does matches a hash in the excluded softwareapplication list, which would occur when a software application has beenchanged, the mobile device 30, or at least some of its functions, can berendered unusable. Alternatively, the mobile device 30 can delete anexcluded application found present on the device transparently to theuser of the device; after successful deletion, the device is restored tooperability.

In many cases, the excluded application list can be maintained remotelyon a remote server or on an external memory device rather than in amemory area local to the device. In such instances, application loadercan transmit a request to the remote server or search the externalmemory device (e.g., memory card, network attached disk, etc.). In suchcases, the remote server consults the excluded list, or the devicesearches the external memory device, to determine whether the to-beinstalled application has been designated as excluded. In the case of aremote server, the remote server would transmit to the device either anapproval or a denial as appropriate. The device could determine approvalor denial directly from its consultation of an external memory device.

When an application installation request is received by a devicesupporting an excluded application list, the excluded application listis consulted based upon the application to-be installed. If theapplication to-be installed is found on the excluded application list,the installation request is denied and the application is not installedon the device. In machines supporting an allowed list and/or a requiredlist in addition to an excluded list, a list priority could beestablished to determine how the device handles installation requestsfor applications that are on multiple lists. For instance, if aparticular application appears on both the required list and theexcluded list, a conflict exists. A priority scheme can be used toresolve such conflicts. In one such scheme, if an application is on therequired list, its presence on other lists is not considered; if anapplication is on the authorized list and the excluded lists, then theapplication is considered excluded as the more conservative approach.

In instances where allowed, required and/or excluded lists aresupported, some or all these lists can be maintained locally within thedevices owner control information store; alternatively, one or moresupported lists could be maintained remotely or on an external memorydevice.

FIG. 4 is a flow diagram illustrating a method of inserting ownerinformation onto an electronic device; this method may be used inconnection with inserting the owner application control information ontothe electronic device. The method in FIG. 4 begins at step 72, when anelectronic device owner establishes owner information. This involvessuch operations as selecting an owner name or identifier and generatingor obtaining an owner digital signature private/public key pair, forexample. The owner information is then digitally signed and sent to theelectronic device at step 74.

At step 76, a determination is made as to whether owner informationalready exists on the electronic device, by checking an ownerinformation store, for example. When owner information does not exist onthe electronic device, such as for an initial insertion of ownerinformation, the owner information is inserted onto the electronicdevice at step 84, by storing the owner information to a memory on theelectronic device. When the owner information is initially beinginserted onto the electronic device, it need not necessarily bedigitally signed. As described above, initial owner informationinsertion may be performed directly by or at least under theauthorization of the owner or an owner system administrator.

A digital signature associated with the owner information is checked atstep 78 where owner information already exists on the electronic device.If the digital signature is not verified, as determined at step 80, theowner information cannot be inserted onto the electronic device, anderror processing is invoked at step 82. As described above, errorprocessing may include such operations as indicating an error or failureon a UI of the electronic device and sending an error or failure messageto an insertion tool or system from which the owner information wassent. The owner information is inserted onto the electronic device atstep 84 where the digital signature was verified.

Once owner information has been inserted onto an electronic device,owner control information is inserted onto the electronic device to setup owner controls. FIG. 5 is a flow diagram illustrating a method ofinserting owner control information onto an electronic device.

At step 92, owner control information is established, based on how anowner wishes to control an electronic device. Owner control information,as described above, may include an authorized software application listand a required software application list, for example. The owner controlinformation is then signed and sent to the electronic device at step 94.The digital signature on the owner control information is then checkedat step 96. At step 98, it is determined whether the digital signatureis verified. Error processing, which may involve operations similar tothose described above in conjunction with step 82 in FIG. 4, isperformed at step 100. If owner information including the owner'sdigital signature public key has not been previously inserted onto theelectronic device, or the owner control information was not signed usingthe digital signature private key corresponding to the owner digitalsignature public key inserted onto the electronic device, then thedigital signature is not verified at step 98.

When the digital signature is verified at step 98, it is then determinedat step 101 whether the received owner control information is current,such as by determining whether a version number of the received ownercontrol information is greater than the version number of existing ownercontrol information. The owner control information is inserted onto theelectronic device at step 102 when the digital signature was verifiedand the received owner control information is current, by storing theinformation to an appropriate data store on the electronic device, forexample. Otherwise, error processing is performed at step 100.

Other operations may also be dependent upon verification of digitalsignatures. For example, commands or requests to write data to or erasedata from an owner information store, an owner control informationstore, or a software application store may be similarly processed toverify associated digital signatures before the commands or requests arecompleted.

The owner control information, such as the software application listsand the application operation restrictions described above, can bemaintained on a remote server managed by the device owner. The remoteserver can maintain a device data store, that may be in the form of adatabase, that stores the control information, including applicationcontrol information, associated with owned devices.

For each device, or for groups of devices, particular application lists(e.g., required, authorized and/or excluded) and allowable operationsfor particular applications can be created, modified, stored anddistributed. In some implementations, a graphical user interface can beprovided through which the owner can specify the particular controlinformation associated with a device or device group.

Owner control information regarding particular applications can beprovided to the electronic device from a remote source (e.g., remotecomputer system server, local memory device such as memory card or disk,etc.) via a wired (or other direct connection based upon physicalcontact of the device with the source) or a wireless (e.g., IR, 802.11,Bluetooth, etc.) communication channel. In such cases, the policyinformation including installation constraints and/or applicationoperation constraints can be provided in a predefined format. Thereceived policy information can then be used to create, update and/ordelete authentication records.

In one implementation, the following format can be used to encode theowner control information regarding an application:

<encoding>=<version><connection set>*<cod file data>*<version> is abyte. The current version is 0.<connection set>=a UTF8 string of comma separated domains<cod file data>=<hash><flags><internal connections set index (abyte)><external connections set index (a byte)>

The download default is specified by a cod file data with a hash of allzeros.

<hash> is a 20 byte SHA1 hash of the cod file<flags> is a 32 bit int.

Required App=1

Excluded App=2

Inter-Process Communication Allowed=4

Internal Network Connections Allowed=8

External Connections Allowed=16

Local Connections Allowed=32

The policy information associated with specific applications can bestored either on a remote server or memory device for delivery to theelectronic device. Such storage can in some instances conform to theabove described format. The policy information can be for an applicationcan be associated with a particular electronic device or a particulargroup of electronic devices. Alternatively, some or all of such policyinformation can be stored remotely and queried upon request from thedevice.

FIG. 9 depicts one possible user interface provided via a remote serverfor an owner to configure application policy information for particularapplications. In this particular example interface, particular groups ofelectronic devices by device type have particular owner controlinformation associated therewith for particular applications. Aninformation technology manager for the device owner can control thepolicy for a given set of devices by changing the provided configurationinformation. Such changes could then be transmitted to individualdevices. In the depicted example, the application list is being used inthe context of constructing a “target configuration” in which thehandheld will be required to have the browser and security applications,as well as the phone application, but the memo pad and tasksapplications are optional (allowed but not required). A user can selecta row as shown at 900 in order to modify one or more of the valuesassociated with an entry.

A remote server can be used to store owner control informationassociated with one or more electronic devices, or groups of devices.The remote server can communicate with the one or more devices via anysuitable communication channel (e.g. wired or wireless connection). Theremote server can use owner control information insertion tools asdescribed herein. The owner control information on the remote server canbe managed in a variety of ways including through provision of amanagement user interface such as the one depicted in FIG. 9. Themanagement user interface can be provided directly by the remote server,or alternatively be provided by a computer system that communicates withthe remote server.

As has been discussed previously, the required, allowed and/or excludedapplication lists can be either locally or remotely (including anexternal memory device) queried, depending upon particularimplementation. In either case, the supported lists can be maintained bya remote server that the owner could control. In the case of an externalmemory device used for list consultation, the memory device could be ashared access device (e.g., network disk) accessible by the device andan owner management system, or the memory device could be a removablemedia or memory card that is temporarily connected to either the remoteserver, or a separate management system in communication with the remoteserver. In the latter case, list information would be stored on thememory device for later insertion or access by the owner controlleddevice.

If lists are locally maintained, the device may periodically or uponoccurrence of specific events (e.g., initialization, installationrequest, etc.) query the remote server for a list or list update. Uponreceipt of a request by the remote server, the server would determinethe list appropriate for the requested device based upon device typeand/or an individual device identifier. The remote server would thentransmit the determined list or list update to the requesting device. Aserver side change to the list could trigger an unsolicited push of thelist to the device. In which case, the server would determine impacteddevices based upon the server side change and transmit the list or listupdate to the impacted devices.

Owner control information is then used to control the electronic device.FIG. 6 is a flow diagram showing a method of owner control of anelectronic device. At step 110, an operation request is received at theelectronic device. Operation requests include, for example, receipt of asoftware application for installation, a function call from a softwareapplication executing on the electronic device, an attempt by a user,software application, or a system on the electronic device to perform anoperation, and the like. Such requests may originate with a user, asoftware application, a device system, or possibly a remote system ordevice. If owner information does not exist on the electronic device, asdetermined at step 112, then owner controls have not been establishedand the operation is performed at step 122. In the example of a receivedsoftware application, step 122 involves installation of the softwareapplication on the electronic device.

When owner information exists, it is determined at step 114 whetherowner control information exists. Error processing operations areperformed at step 116 if owner information, but not owner controlinformation, exists. As described above, determining whether ownerinformation exists at step 112, and then reverting to error processingat step 116 where it is determined at step 114 that owner controlinformation does not exist prevents certain operations, such as softwareapplication loading and installation, when an owner information has beeninserted onto an electronic device, but owner control information hasnot yet been inserted. Step 116 may include such operations aspresenting an error message to a user of the electronic device andreturning an error indication to a source from which the operationrequest was received. Alternatively, a default action in response to anegative determination at step 114 could be to revert to step 122, whenan owner does not wish to restrict device operations before ownercontrol information is inserted.

When both owner information and owner control information have beeninserted onto an electronic device, it is determined at step 118 whetherthe operation is permitted. In the case of a received softwareapplication, step 118 involves determining whether software applicationinstallation is permitted, and possibly whether the software applicationis an authorized software application. In the case of authorizedapplications, the requested operation could include, for example, anapplication requesting opening a connection (e.g., networkconnection—MDS, WAP, SMS, TCP, etc. or local—USB, serial, etc.),accessing the telephone API, accessing local memory or communicatingwith other applications executing on the device. The operation isperformed at step 122 where the operation is permitted. Otherwise, errorprocessing is performed at step 120. As described above, owner controlinformation may include not only permissions and restrictions forelectronic device operations and software applications, but also a listof required software applications or modules which may be checked fromtime to time to ensure that all required software applications arepresent on an electronic device. For example, an electronic device maybe configured to check for required software applications at step 118when certain types of operation requests are received, and to performthe operation at step 122 only when all required software applicationsare found.

It will be appreciated that the above description relates to theinvention by way of example only. Many variations on the systems andmethods described above will occur to those knowledgeable in the field,and such variations are within the scope of this application, whether ornot expressly described. For example, a system and method can beconfigured to receive an operation request from an application. Thedevice can determine (e.g., through software instructions) whether therequested operation is allowed to be performed by the application basedupon a stored authorization record and an application identifierassociated with the application. The application is allowed to performthe requested operation based upon whether the requested operation isdetermined to be allowed to be performed by the application.

As another example, a system (e.g., via software instructions) andmethod can be configured to: receive an operation request from anapplication; wherein the requested operation is selected from the groupconsisting of: opening a connection, accessing a telephone API,accessing local memory and communicating with another executingapplication; determine whether the requested operation is allowed to beperformed by the application based upon a stored authorization recordand an application identifier associated with the application; whereinthe stored authorization record is associated with data indicative ofwhether the application is required, allowed, or excluded; wherein theauthorization record related to determining whether the requestedoperation is to be allowed is provided by an external computer that isused to enforce policies for operating electronic devices within anorganization; to allow the application to perform the requestedoperation based upon whether the requested operation is determined to beallowed to be performed by the application.

Still further as another example, owner information and owner controlinformation operations may be secured by other means than digitalsignatures. Instead of checking digital signatures on owner information,owner control information, and restricted commands or requests, anelectronic device might issue a cryptographic challenge using apreviously inserted encryption key associated with the owner. Theencryption key could be a public key of the owner or a secret key sharedbetween the owner and the electronic device. Operations such as ownerinformation or owner control information insertion or erasure would thenbe performed only when a valid challenge response is returned. A validchallenge response may only be generated using a correspondingencryption key. Data integrity and source authentication could insteadbe assumed, for example, where owner information and owner controlinformation are sent to an electronic device over a secure channel. Ifthe device properly decrypts information received via the securechannel, then it is assumed that the information is valid and was sentby an authorized source. In this latter scheme, the source and deviceshare a public/private key pair, or a common symmetric key.

In some instances, owner control information such as owner applicationcontrol information can reside on a remote server rather than on theelectronic device. For instance, one or more of a required, authorizedand/or excluded application list can reside on a remote server. In suchinstances, an operation request such as application installation ordevice initialization can generate a query to the remote server wheresuch lists reside. The proper list can be consulted and an appropriateresponse returned to the inquiring device.

In addition, an electronic device in which systems and methods describedabove are implemented may include fewer, further, or additionalcomponents than shown in FIGS. 2 and 3. FIG. 7 is a block diagram of awireless mobile communication device as an example of such an electronicdevice. However, it should be understood that the systems and methodsdisclosed herein may be used with many different types of devices, suchas personal digital assistants (PDAS) and desktop computers.

As shown in FIG. 7, mobile device 500 is preferably a two-waycommunication device having at least voice and data communicationcapabilities. The mobile device 500 preferably has the capability tocommunicate with other computer systems on the Internet. Depending onthe functionality provided by the mobile device, the mobile device maybe referred to as a data messaging device, a two-way pager, a cellulartelephone with data messaging capabilities, a wireless Internetappliance, or a data communication device (with or without telephonycapabilities).

The mobile device 500 includes a transceiver 511, a microprocessor 538,a display 522, non-volatile memory 524, random access memory (RAM) 526,auxiliary input/output (I/O) devices 528, a serial port 530, a keyboard532, a speaker 534, a microphone 536, a short-range wirelesscommunications sub-system 540, and may also include other devicesub-systems 542. The transceiver 511 preferably includes transmit andreceive antennas 516, 518, a receiver (Rx) 512, a transmitter (Tx) 514,one or more local oscillators (LOs) 513, and a digital signal processor(DSP) 520. Within the non-volatile memory 524, the mobile device 500includes a plurality of software modules 524A-524N that can be executedby the microprocessor 538 (and/or the DSP 520), including a voicecommunication module 524A, a data communication module 524B, and aplurality of other operational modules 524N for carrying out a pluralityof other functions.

The mobile device 500 is preferably a two-way communication devicehaving voice and data communication capabilities. Thus, for example, themobile device 500 may communicate over a voice network, such as any ofthe analog or digital cellular networks, and may also communicate over adata network. The voice and data networks are depicted in FIG. 7 by thecommunication tower 519. These voice and data networks may be separatecommunication networks using separate infrastructure, such as basestations, network controllers, etc., or they may be integrated into asingle wireless network. References to the network 519 should thereforebe interpreted as encompassing both a single voice and data network andseparate networks.

The communication subsystem 511 is used to communicate with the network519. The DSP 520 is used to send and receive communication signals toand from the transmitter 514 and receiver 512, and also exchange controlinformation with the transmitter 514 and receiver 512. If the voice anddata communications occur at a single frequency, or closely-spaced setof frequencies, then a single LO 513 may be used in conjunction with thetransmitter 514 and receiver 512. Alternatively, if differentfrequencies are utilized for voice communications versus datacommunications or the mobile device 500 is enabled for communications onmore than one network 519, then a plurality of LOs 513 can be used togenerate frequencies corresponding to those used in the network 519.Although two antennas 516, 518 are depicted in FIG. 7, the mobile device500 could be used with a single antenna structure. Information, whichincludes both voice and data information, is communicated to and fromthe communication module 511 via a link between the DSP 520 and themicroprocessor 538.

The detailed design of the communication subsystem 511, such asfrequency band, component selection, power level, etc., is dependentupon the communication network 519 in which the mobile device 500 isintended to operate. For example, a mobile device 500 intended tooperate in a North American market may include a communication subsystem511 designed to operate with the Mobitex or DataTAC mobile datacommunication networks and also designed to operate with any of avariety of voice communication networks, such as AMPS, TDMA, CDMA, PCS,etc., whereas a mobile device 500 intended for use in Europe may beconfigured to operate with the GPRS data communication network and theGSM voice communication network. Other types of data and voice networks,both separate and integrated, may also be utilized with the mobiledevice 500.

Communication network access requirements for the mobile device 500 alsovary depending upon the type of network 519. For example, in the Mobitexand DataTAC data networks, mobile devices are registered on the networkusing a unique identification number associated with each device. InGPRS data networks, however, network access is associated with asubscriber or user of the mobile device 500. A GPRS device typicallyrequires a subscriber identity module (“SIM”), which is required inorder to operate the mobile device 500 on a GPRS network. Local ornon-network communication functions (if any) may be operable, withoutthe SIM, but the mobile device 500 is unable to carry out functionsinvolving communications over the network 519, other than any legallyrequired operations, such as ‘911’ emergency calling.

After any required network registration or activation procedures havebeen completed, the mobile device 500 is able to send and receivecommunication signals, preferably including both voice and data signals,over the network 519. Signals received by the antenna 516 from thecommunication network 519 are routed to the receiver 512, which providesfor signal amplification, frequency down conversion, filtering, channelselection, etc., and may also provide analog to digital conversion.Analog to digital conversion of the received signal allows more complexcommunication functions, such as digital demodulation and decoding, tobe performed using the DSP 520. In a similar manner, signals to betransmitted to the network 519 are processed, including modulation andencoding, for example, by the DSP 520 and are then provided to thetransmitter 514 for digital to analog conversion, frequency upconversion, filtering, amplification and transmission to thecommunication network 519 via the antenna 518. Although a singletransceiver 511 is shown for both voice and data communications, inalternative embodiments, the mobile device 500 may include multipledistinct transceivers, such as a first transceiver for transmitting andreceiving voice signals, and a second transceiver for transmitting andreceiving data signals, or a first transceiver configured to operatewithin a first frequency band, and a second transceiver configured tooperate within a second frequency band.

In addition to processing the communication signals, the DSP 520 alsoprovides for receiver and transmitter control. For example, the gainlevels applied to communication signals in the receiver 512 andtransmitter 514 may be adaptively controlled through automatic gaincontrol algorithms implemented in the DSP 520. Other transceiver controlalgorithms could also be implemented in the DSP 520 in order to providemore sophisticated control of the transceiver 511.

The microprocessor 538 preferably manages and controls the overalloperation of the mobile device 500. Many types of microprocessors ormicrocontrollers could be used here, or, alternatively, a single DSP 520could be used to carry out the functions of the microprocessor 538.Low-level communication functions, including at least data and voicecommunications, are performed through the DSP 520 in the transceiver511. High-level communication applications, including the voicecommunication application 524A, and the data communication application524B are stored in the non-volatile memory 524 for execution by themicroprocessor 538. For example, the voice communication module 524A mayprovide a high-level user interface operable to transmit and receivevoice calls between the mobile device 500 and a plurality of other voicedevices via the network 519. Similarly, the data communication module524B may provide a high-level user interface operable for sending andreceiving data, such as e-mail messages, files, organizer information,short text messages, etc., between the mobile device 500 and a pluralityof other data devices via the network 519.

The microprocessor 538 also interacts with other device subsystems, suchas the display 522, RAM 526, auxiliary I/O devices 528, serial port 530,keyboard 532, speaker 534, microphone 536, a short-range communicationssubsystem 540 and any other device subsystems generally designated as542. For example, the modules 524A-N are executed by the microprocessor538 and may provide a high-level interface between a user of the mobiledevice and the mobile device. This interface typically includes agraphical component provided through the display 522, and aninput/output component provided through the auxiliary I/O devices 528,keyboard 532, speaker 534, or microphone 536. Such interfaces aredesignated generally as UI 46 in FIG. 3.

Some of the subsystems shown in FIG. 7 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 532 and display522 may be used for both communication-related functions, such asentering a text message for transmission over a data communicationnetwork, and device-resident functions such as a calculator or task listor other PDA type functions.

Operating system software used by the microprocessor 538 is preferablystored in a persistent store such as the non-volatile memory 524. Inaddition to the operating system and communication modules 524A-N, thenon-volatile memory 524 may include a file system for storing data. Thenon-volatile memory 524 may also include data stores for ownerinformation and owner control information. The operating system,specific device applications or modules, or parts thereof, may betemporarily loaded into a volatile store, such as RAM 526 for fasteroperation. Moreover, received communication signals may also betemporarily stored to RAM 526, before permanently writing them to a filesystem located in the non-volatile memory 524. The non-volatile memory524 may be implemented, for example, with Flash memory, non-volatileRAM, or battery backed-up RAM.

An exemplary application module 524N that may be loaded onto the mobiledevice 500 is a PIM application providing PDA functionality, such ascalendar events, appointments, and task items. This module 524N may alsointeract with the voice communication module 524A for managing phonecalls, voice mails, etc., and may also interact with the datacommunication module 524B for managing e-mail communications and otherdata transmissions. Alternatively, all of the functionality of the voicecommunication module 524A and the data communication module 524B may beintegrated into the PIM module.

The non-volatile memory 524 preferably provides a file system tofacilitate storage of PIM data items on the device. The PIM applicationpreferably includes the ability to send and receive data items, eitherby itself, or in conjunction with the voice and data communicationmodules 524A, 524B, via the wireless network 519. The PIM data items arepreferably seamlessly integrated, synchronized and updated, via thewireless network 519, with a corresponding set of data items stored orassociated with a host computer system, thereby creating a mirroredsystem for data items associated with a particular user.

The mobile device 500 is manually synchronized with a host system byplacing the mobile device 500 in an interface cradle, which couples theserial port 530 of the mobile device 500 to a serial port of the hostsystem. The serial port 530 may also be used to insert owner informationand owner control information onto the mobile device 500 and to downloadother application modules 524N for installation on the mobile device500. This wired download path may further be used to load an encryptionkey onto the mobile device 500 for use in secure communications, whichis a more secure method than exchanging encryption information via thewireless network 519.

Owner information, owner control information and additional applicationmodules 524N may be loaded onto the mobile device 500 through thenetwork 519, through an auxiliary I/O subsystem 528, through theshort-range communications subsystem 540, or through any other suitablesubsystem 542, and installed by a user in the non-volatile memory 524 orRAM 526. Such flexibility in application installation increases thefunctionality of the mobile device 500 and may provide enhancedon-device functions, communication-related functions, or both. Forexample, secure communication applications may enable electroniccommerce functions and other such financial transactions to be performedusing the mobile device 500.

When the mobile device 500 is operating in a data communication mode, areceived signal, such as a text message or a web page download, will beprocessed by the transceiver 511 and provided to the microprocessor 538,which preferably further processes the received signal for output to thedisplay 522, or, alternatively, to an auxiliary I/O device 528. Ownerinformation, owner control information, commands or requests related toowner information or owner control information, and softwareapplications received by the transceiver 511 are processed as describedabove. A user of mobile device 500 may also compose data items, such asemail messages, using the keyboard 532, which is preferably a completealphanumeric keyboard laid out in the QWERTY style, although otherstyles of complete alphanumeric keyboards such as the known DVORAK stylemay also be used. User input to the mobile device 500 is furtherenhanced with the plurality of auxiliary I/O devices 528, which mayinclude a thumbwheel input device, a touchpad, a variety of switches, arocker input switch, etc. The composed data items input by the user arethen transmitted over the communication network 519 via the transceiver511.

When the mobile device 500 is operating in a voice communication mode,the overall operation of the mobile device 500 is substantially similarto the data mode, except that received signals are output to the speaker534 and voice signals for transmission are generated by a microphone536. In addition, the secure messaging techniques described above mightnot necessarily be applied to voice communications. Alternative voice oraudio I/O devices, such as a voice message recording subsystem, may alsobe implemented on the mobile device 500. Although voice or audio signaloutput is accomplished through the speaker 534, the display 522 may alsobe used to provide an indication of the identity of a calling party, theduration of a voice call, or other voice call related information. Forexample, the microprocessor 538, in conjunction with the voicecommunication module 524A and the operating system software, may detectthe caller identification information of an incoming voice call anddisplay it on the display 522.

A short-range communications subsystem 540 is also be included in themobile device 500. For example, the subsystem 540 may include aninfrared device and associated circuits and components, or a Bluetoothor 802.11 short-range wireless communication module to provide forcommunication with similarly-enabled systems and devices. Thus, ownerinformation insertion, owner control information insertion, andapplication loading operations as described above may be enabled on themobile device 500 via the serial port 530 or other short-rangecommunications subsystem 540.

It is to be understood that FIG. 7 represents an example of anelectronic device in which owner control systems and methods describedabove may be implemented. Implementation of such systems and methods inother electronic devices having further, fewer, or different componentsthan those shown in FIG. 7 would occur to one skilled in the art towhich this application pertains and are therefore considered to bewithin the scope of the present application. For example, although a SIMcard has not been explicitly shown in FIG. 7, it should be appreciatedthat implementation of owner control systems and methods in electronicdevices with SIM cards is contemplated. Since SIM cards currentlyincorporate a memory component, owner information, owner controlinformation, or both, may be inserted onto a SIM card and used tomaintain owner control of an electronic device when the SIM card isinstalled in the electronic device. In this case, a SIM card could bebranded by inserting owner information onto the SIM card, and ownercontrol information could then be inserted onto the SIM card or anelectronic device in which the SIM card is installed.

1. A method of application control for use on an electronic device, themethod comprising: receiving an operation request from an application;determining whether the requested operation is allowed to be performedby the application based upon a stored authorization record and anapplication identifier associated with the application; and allowing theapplication to perform the requested operation based upon whether therequested operation is determined to be allowed to be performed by theapplication.
 2. The method of claim 1, wherein the application isallowed to perform the requested operation only if the requestedoperation is determined to be allowed to be performed by theapplication.
 3. The method of claim 1, wherein the authorization recordand the application identifier are provided by an external source forstorage on the electronic device.
 4. The method of claim 3, wherein theauthorization record and the application identifier are provided by theexternal source to the electronic device through a wirelesscommunication channel.
 5. The method of claim 3, wherein theauthorization record related to determining whether the requestedoperation is to be allowed is provided by an external computer that isused to enforce policies for operating electronic devices within anorganization.
 6. The method of claim 1, wherein an update to theauthorization record is provided by an external source for storage onthe electronic device.
 7. The method of claim 1, wherein a plurality ofauthorization records associated with a plurality of applicationidentifiers are stored on the electronic device, said method furthercomprising: receiving operation requests from a plurality ofapplications operating on the electronic device; determining whether therequested operations are allowed to be performed by their respectiveapplications based upon the stored authorization records and theapplication identifiers that are respectively associated with theplurality of applications; and allowing the plurality of applications toperform their respective requested operations based upon whether therequested operations are determined to be allowed to be performed. 8.The method of claim 7, wherein a group containing two or more of theapplications is associated with one of the authorization records.
 9. Themethod of claim 1, wherein the requested operation is selected from thegroup consisting of: opening a connection; accessing a telephone API;accessing local memory; or communicating with another executingapplication.
 10. The method of claim 1, wherein the requested operationis selected from the group consisting of: opening network connectionsinside a firewall; opening network connections outside the firewall;opening local connections; interacting with other processes; accessing aruntime store or a persistent store; or accessing a telephone API inorder to make a phone call through the electronic device.
 11. The methodof claim 1, wherein the stored authorization record is associated withdata indicative of whether the application is required, allowed, orexcluded.
 12. The method of claim 1, wherein the authorization record isstored in a protected data store thereby preventing alteration ordeletion to the authorization record unless permitted.
 13. The method ofclaim 1, wherein the electronic device is a wireless mobilecommunications device or a personal digital assistant (PDA).
 14. One ormore computer readable media storing instructions that upon execution bythe electronic device cause the electronic device perform the steps ofclaim
 1. 15. A data signal that is transmitted using a communicationchannel, wherein the data signal includes the authorization record ofclaim 1 for use by the electronic device for determining whether arequested operation is allowed to be performed.
 16. The method of claim1, wherein the application operates upon the electronic device.
 17. Asystem of application control for use on an electronic device,comprising: an authorization record store configured to store operationauthorization data records and application identifiers that areassociated with the operation authorization data records; softwareinstructions that are configured to consult the operation authorizationdata in the authorization record store in order to determine whether anoperation requested by an application operating on the electronic deviceis allowed to be performed by the application; wherein the applicationidentifiers associated with the operation authorization data records areused to determine which of the operation authorization data records isto be used by the software instructions in determining whether to permitthe requested operation.
 18. A system of application control for use onwireless mobile communications device, comprising: means for receivingan operation request from an application; wherein the requestedoperation is selected from the group consisting of: opening aconnection, accessing a telephone API, accessing local memory andcommunicating with another executing application; means for determiningwhether the requested operation is allowed to be performed by theapplication based upon a stored authorization record and an applicationidentifier associated with the application; wherein the storedauthorization record is associated with data indicative of whether theapplication is required, allowed, or excluded; wherein the authorizationrecord related to determining whether the requested operation is to beallowed is provided by an external computer that is used to enforcepolicies for operating electronic devices within an organization; meansfor allowing the application to perform the requested operation basedupon whether the requested operation is determined to be allowed to beperformed by the application.